r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Is this motivated by concrete codegen improvements (the codegen tests are quite artificial)? assume/assert_unchecked always has the potential to go either way wrt performance, so it would be good to know whether you've confirmed that this improves real-world code

Interesting that llvm can already infer some bounds, but apparently not the tightest ones. Looking at the following functions in compiler explorer, there are no panics:

pub fn test_u8(i: std::num::NonZeroU8, a: &[u32; 3]) -> u32 {
    a[i.ilog10() as usize]
}

pub fn test_u16(i: std::num::NonZeroU16, a: &[u32; 8]) -> u32 {
    a[i.ilog10() as usize]
}

pub fn test_u32(i: std::num::NonZeroU32, a: &[u32; 13]) -> u32 {
    a[i.ilog10() as usize]
}

pub fn test_u64(i: std::num::NonZeroU64, a: &[u32; 23]) -> u32 {
    a[i.ilog10() as usize]
}

These functions with tighter bounds would make for nicer codegen test.

@Noratrieb: An example would be getting a slice of digits of an integer where adding an assertion can remove bound checking code:

pub fn get_digits(mut x: u32, buffer: &mut [u8; 10]) -> &mut [u8] {
    let digits = &mut buffer[..x.checked_ilog10().unwrap_or_default() as usize + 1];

    for slot in &mut *digits {
        *slot = (x % 10) as u8;
        x /= 10;
    }

    digits
}

You can compare the the codegen results here.

Also, isqrt already have a similar assertion like this:

I think it is reasonable that we do the same on ilog10, otherwise it is difficult to explain why is there behavior difference between isqrt and ilog10.